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STATEMENT  OF  INTENT 


The  Consultative  Committee  for  Space  Data  Systems  (CCSDS)  is  an  organization  officially 
established  by  the  management  of  member  space  Agencies.  The  Committee  meets 
periodically  to  address  data  systems  problems  that  are  common  to  all  participants,  and  to 
formulate  sound  technical  solutions  to  these  problems.  Inasmuch  as  participation  in  the 
CCSDS  is  completely  voluntary,  the  results  of  Committee  actions  are  termed 
RECOMMENDATIONS  and  are  not  considered  binding  on  any  Agency. 

This  RECOMMENDATION  is  issued  by,  and  represents  the  consensus  of,  the  CCSDS 
Plenary  body.  Agency  endorsement  of  this  RECOMMENDATION  is  entirely  voluntary. 
Endorsement,  however,  indicates  the  following  understandings: 

o  Whenever  an  Agency  establishes  a  CCSDS-related  STANDARD,  this  STANDARD 
will  be  in  accord  with  the  relevant  RECOMMENDATION.  Establishing  such  a 
STANDARD  does  not  preclude  other  provisions  which  an  Agency  may  develop. 

o  Whenever  an  Agency  establishes  a  CCSDS-related  STANDARD,  the  Agency  will 
provide  other  CCSDS  member  Agencies  with  the  following  information: 

—  The  STANDARD  itself. 

—  The  anticipated  date  of  initial  operational  capability. 

—  The  anticipated  duration  of  operational  service. 

o  Specific  service  arrangements  shall  be  made  via  memoranda  of  agreement.  Neither  this 
RECOMMENDATION  nor  any  ensuing  STANDARD  is  a  substitute  for  a 
memorandum  of  agreement. 

No  later  than  five  years  from  its  date  of  issuance,  this  Recommendation  will  be  reviewed  by 
the  CCSDS  to  determine  whether  it  should:  (1)  remain  in  effect  without  change;  (2)  be 
changed  to  reflect  the  impact  of  new  technologies,  new  requirements,  or  new  directions;  or 
(3)  be  retired  or  canceled 

In  those  instances  when  a  new  version  of  a  RECOMMENDATION  is  issued,  existing 
CCSDS-related  Agency  standards  and  implementations  are  not  negated  or  deemed  to  be  non- 
CCSDS  compatible.  It  is  the  responsibility  of  each  Agency  to  determine  when  such 
standards  or  implementations  are  to  be  modified.  Each  Agency  is,  however,  strongly 
encouraged  to  direct  planning  for  its  new  standards  and  implementations  towards  the  later 
version  of  the  Recommendation. 
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FOREWORD 


This  document,  which  is  a  technical  Recommendation  prepared  by  the  Consultative 
Committee  for  Space  Data  Systems  (CCSDS),  is  intended  for  use  by  participating  space 
Agencies  in  their  development  of  space  telecommand  systems. 

This  Recommendation  allows  the  implementing  organizations  within  each  Agency  to 
proceed  coherently  with  the  development  of  compatible  Standards  for  the  flight  and  ground 
systems  that  are  within  their  cognizance.  Agency  Standards  derived  from  this 
Recommendation  may  implement  only  a  subset  of  the  optional  features  allowed  herein,  or 
may  incorporate  features  not  addressed  by  the  Reconunendation. 

In  order  to  establish  a  common  framework  within  which  the  Agencies  may  develop 
standardized  telecommand  services,  the  CCSDS  advocates  adoption  of  a  layered  systems 
architecture.  Within  this  approach,  specific  layers  of  service  (including  their  operational 
protocol  and  data  structuring  techniques)  may  be  selected  for  implementation  according  to 
mission  requirements. 

The  current  layered  set  of  CCSDS  telecommand  Recommendations  was  developed  to  match 
the  conventional  free-flying  mission  environment,  as  characterized  by  the  transmission  of 
conunand  data  at  relatively  low  uplink  data  rates  to  spacecraft  of  moderate  complexity. 
Advanced  Orbiting  Systems  (AOS),  which  are  characterized  by  a  more  complex  mission 
environment,  including  the  transmission  of  multiple  data  types  at  very  high  data  rates  to 
space  vehicles  which  include  extensive  onboard  data  networking  capability,  may  choose  to 
use  the  AOS  protocols  and  data  structures  defined  in  Reference  [8]  for  both  uplink  and 
downlink  or  they  may  use  the  telecommand  data  structures  and  protocols  defined  here  for 
uplink. 

This  Recommendation  for  Telecommand  Data  Routing  Service  was  developed  within  the 
layered  architectural  framework,  and  embraces  the  standard  data  structures  and  data 
communication  procedures  which  may  be  used  by  conventional  missions  within  the 
intermediate  telecommand  system  layers. 

Through  the  process  of  normal  evolution,  it  is  expected  that  expansion,  deletion  or 
modification  to  this  document  may  occur.  This  Recommendation  is  therefore  subject  to 
CCSDS  document  management  and  change  control  procedures  which  are  defined  in 
Reference[l]. 
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1  INTRODUCTION 

1.1  PURPOSE  AND  SCOPE 

The  purpose  of  this  document  is  to  establish  a  common  Recommendation  for  the 
implementation  of  a  spacecraft  telecommand  “Data  Routing  Service”  by  the  Agencies 
participating  in  the  Consultative  Committee  for  Space  Data  Systems  (CCSDS).  The 
operating  principles  and  procedures  for  the  CCSDS  are  defined  in  Reference  [1].  The 
context  of  the  Data  Routing  Service  within  the  overall  Telecommand  System  is  described  in 
Reference  [2]. 

This  Recommendation  addresses  the  procedures  and  data  unit  formats  implemented  within 
the  Segmentation  layer  and  the  Transfer  layer  of  the  telecommand  Data  Routing  Service. 

1.2  APPLICABILITY 

This  Recommendation  serves  as  a  guideline  for  the  development  of  compatible  internal 
Agency  standards  in  the  field  of  conventional  spacecraft  commanding.  This 
Recommendation  is  not  retroactive,  nor  does  it  commit  any  Agency  to  implement  the 
recommended  telecommand  concepts  at  any  future  time.  Nevertheless,  all  CCSDS  Agencies 
accept  the  principle  that  all  future  implementations  of  telecommand  which  are  used  in  cross¬ 
support  situations  will  be  based  on  this  Recommendation. 

The  CCSDS  has  developed  a  layered  concept  for  conventional  spacecraft  telecommanding, 
which  is  summarized  in  Reference  [2].  Standard  services  are  defined  within  each  layer,  and 
Agencies  will  be  encouraged  to  develop  corresponding  facilities  to  provide  these  services  in 
support  of  Projects. 

To  be  fully  compatible  with  the  CCSDS  concept,  a  conventional  Project’s  telecommanding 
architecture  should  follow  this  Recommendation  for  Data  Routing  Service,  plus  the 
Recommendations  for  telecommand  “Data  Management  Service”  and  telecommand 
“Channel  Service”,  which  are  described  in  References  [3]  and  [4].  Projects  may  also  elect  to 
be  partially  compatible  with  the  concept  by  interfacing  with  the  standard  systems  at 
intermediate  layers  within  any  of  the  service  specifications. 

Advanced  Orbiting  Systems  (AOS)  may  use  the  AOS  data  structures  and  protocols  defined 
in  Reference  [8]  for  uplinking  data  and  control  information  or  they  may  use  the  telecommand 
data  structures  and  protocols  defined  here  and  in  References  [3],  [4]  and  [7]  in  a  hybrid 
fashion.  See  Reference  [9]  for  a  discussion  of  hybrid  support. 

Where  preferred  options  or  mandatory  capabilities  are  clearly  indicated  herein,  the  indicated 
sections  of  the  specification  must  be  implemented  when  this  Recommendation  is  used  as  a 
basis  for  cross-support.  Where  optional  subsets  or  capabilities  are  allowed  or  implied  in  this 
specification,  implementation  of  these  options  or  subsets  is  subject  to  specific  bilateral  cross¬ 
support  agreements  between  the  Agencies  involved. 
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The  recommendations  in  this  document  are  to  be  invoked  through  the  normal  standards 
programs  of  each  member  Agency,  and  are  applicable  to  those  missions  for  which  cross¬ 
support  based  on  capabilities  described  in  these  recommendations  is  anticipated. 

1.3  BIT  NUMBERING  CONVENTION  AND  NOMENCLATURE 

In  this  document,  the  following  convention  is  used  to  identify  each  bit  in  an  N-bit  field: 

The  first  bit  in  the  field  to  be  transferred  (i.e.,  the  most  left  justified  when  drawing  a  figure)  is 
defined  to  be  “Bit  0”;  the  following  bit  is  defined  to  be  “Bit  1”  and  so  on  up  to  “Bit  N-l”. 
When  the  field  is  used  to  express  a  binary  value  (such  as  a  counter),  the  Most  Significant  Bit 
(MSB)  shall  be  the  first  bit  of  the  field,  i.e.,  “Bit  0”. 


BITO  BITN-1 

V _ V 

N-BIT  DATA  FIELD 


li 

FIRST  BIT  TRANSFERRED  =  MSB 


In  accordance  with  modern  data  communications  practice,  spacecraft  data  fields  are  often 
grouped  into  8-bit  “words”  which  conform  to  the  above  convention.  Throughout  this 
Recommendation,  the  following  nomenclature  is  used  to  describe  this  grouping: 


8-BIT  WORD  =  "OCTET" 


By  CCSDS  convention,  all  “spare”  bits  shall  be  permanently  set  to  value  “zero”. 

Note  that  throughout  this  document,  the  word  “Telecommand”  may  be  abbreviated  as  “TC”. 
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2  TELECOMMAND  DATA  ROUTING  SERVICE  OVERVIEW 

A  complete  summary  of  the  acronyms  and  terminology  used  internal  to  this  document  is 
presented  in  Annex  A.  A  detailed  specification  of  the  services  provided  by  each  layer  is 
presented  in  Annex  B. 

Figure  2-1  illustrates  the  significance  of  the  Telecommand  (TC)  Data  Routing  Service  in  the 
overall  Telecommand  System,  which  contains  three  principal  service  elements: 
Telecommand  Data  Management  Service;  Telecommand  Data  Routing  Service;  and 
Telecommand  Channel  Service.  Each  service  is  documented  in  its  own  Recommendation.  A 
more  thorough  discussion  of  the  layered  services,  including  expansion  of  Figure  2-1  in 
greater  detail,  is  contained  in  Reference  [2].  The  Telecommand  System  is  related  to  the 
Telemetry  System  as  documented  in  Reference  [5]  and  Reference  [6]. 

The  TC  Data  Routing  Service  enables  user  telecommand  data  units  associated  with  higher 
layers  to  be  reliably  transferred  to  the  spacecraft,  drawing  upon  the  Channel  Service  to 
perform  its  functions.  The  Data  Routing  Service  contains  two  distinct  layers  of  data  handling 
operations: 

(1)  A  SEGMENTATION  layer,  which  prepares  the  user  data  units  for  transfer  by 
forming  them  into  suitable-sized  routable  pieces  and  permitting  these  pieces  to  be 
multiplexed  together  for  transmission  through  the  command  channel. 

(2)  A  TRANSFER  layer,  which  encapsulates  the  routable  pieces  of  user  data  into 
transfer  data  structures  and  controls  their  transmission  through  the  channel, 
including  any  retransmissions  needed  to  ensure  delivery  of  the  routable  pieces  in 
sequence  without  gaps  or  duplication. 

The  detailed  specification  of  the  retransmission  mechanism,  called  the  Command  Operation 
Procedure,  is  given  in  Part  2.1  of  the  Telecommand  Recommendation  (Reference  [7]). 

The  Data  Routing  Service  provides  an  interface  between  the  high-layer  “user”  elements  of 
the  TC  System  and  the  low-layer  communications  channel  through  which  data  flow. 

Because  the  underlying  Channel  Service  inherently  includes  a  noisy  signal  path,  there  is  a 
finite  probability  that  it  will  introduce  an  error.  Since  any  error  in  the  user’s  data  will  render 
them  invalid,  it  is  desirable  to  break  large  user  data  units  into  relatively  small  pieces  (which 
will  thus  each  have  a  lower  probability  of  being  invalidated  by  transmission  error  than  if  the 
entire  user  data  unit  were  sent  contiguously).  This  improves  system  throughput  efficiency 
since  only  small  pieces  have  to  be  retransmitted  when  errors  are  detected.  However,  there 
may  also  be  situations  in  which  the  user  data  units  are  very  small.  For  efficient  transfer,  the 
Data  Routing  Service  provides  the  capability  to  group  these  small  units  into  larger  pieces. 

Analysis  of  the  performance  of  the  Channel  Service  and  Data  Routing  Service  under  various 
conditions  is  contained  in  Reference  [2]. 
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Figure  2-1:  Telecommand  System 
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NOTE  A: 


NOTE  B: 


NOTE  C: 


Figure  2-1  represents  a  logical  view  of  the  TC  System,  and  physical 
implementations  may  not  necessarily  correspond  to  the  sequential  flow  of 
operations  implied  by  the  figure. 

This  Recommendation  primarily  specifies  the  data  structures  and  protocols 
flowing  ACROSS  the  layers  of  the  TC  System,  since  these  have  a  direct  impact 
on  the  long  lead-time  design  of  future  spacecraft  hardware  and  software. 
Comprehensive  definition  of  the  associated  flow  of  control  instructions,  which 
are  required  to  initialize  the  layers  and  to  direct  the  flow  of  TC  data  units 
BETWEEN  the  layers,  remains  an  item  for  potential  future  extension  of  this 
document. 

Although  the  layers  defined  in  this  document  may  be  used  without  necessarily 
implementing  those  defined  in  the  Channel  Service  (Reference  [4])  and  Data 
Management  Service  (Reference  [3]),  the  names  of  the  layers  in  those  Services 
will  be  used  to  denote  the  external  interfaces  for  the  Data  Routing  Service,  when 
appropriate. 
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3  SEGMENTATION  LAYER:  STANDARD  DATA  STRUCTURES 
AND  PROCEDURES 

3.1  OVERVIEW  OF  THE  LAYER 

The  data  unit  received  by  the  Segmentation  layer  from  the  higher  layer  is  called  a  “TC  User 
Data  Unit”.  If  the  higher  layer  is  the  Packetization  layer,  defined  in  Reference  [3],  it  will  be 
a  TC  Packet;  otherwise,  it  may  be  any  other  user-provided  data  unit. 

The  data  unit  passed  from  the  Segmentation  layer  to  the  Transfer  layer  is  the  “TC  Frame  Data 
Unit”.  It  will  normally  consist  of  a  TC  Segment.  If  neither  segmentation  nor  multiplexing  is 
used  on  a  particular  Virtual  Channel,  the  Segment  Header  may  be  omitted  on  that  Virtual 
Channel. 

The  TC  Segmentation  layer  accepts  variable-length  TC  User  Data  Units  from  the  layer  above 
and  prepares  them  for  transmission  by  the  layers  below  by: 

(1)  forming  the  TC  User  Data  Units  into  TC  Frame  Data  Units,  which  are  compatible 
with  insertion  into  the  data  field  of  the  TC  Transfer  Frame. 

(2)  enabling  TC  User  Data  Units  from  different  sources  to  be  multiplexed  together  so 
that  they  may  share  one  Virtual  Channel. 

To  accomplish  service  (1),  the  Segmentation  layer  breaks  large  TC  User  Data  Units  into 
smaller  TC  Segments  or  aggregates  small  TC  Packets  into  a  larger  TC  Segment  or  TC  Frame 
Data  Unit. 

To  accomplish  service  (2),  the  Segmentation  layer  provides  “Multiplexer  Access  Points” 
(MAPs).  A  TC  User  Data  Unit  arriving  at  the  input  to  the  Segmentation  layer  is  allocated  to 
a  MAP  at  the  sending  end  of  the  layer  and  is  transferred  to  the  corresponding  MAP  at  the 
receiving  end  of  the  layer  using  the  transfer  service  of  the  layers  below.  The  layers  below 
may  provide  one  “real”  physical  channel,  or  may  logically  divide  the  real  channel  into 
multiple,  named  “Virtual  Channels”  (as  defined  in  Section  4).  Each  of  “m”  (m  =  1  to  64) 
Virtual  Channels  (VCs)  may  have  “n”  (n  =  1  to  64)  distinct  MAPs  associated  with  it.  The 
orientation  of  the  Segmentation  layer  is  shown  in  Figure  3-1. 

Section  3.2  defines  the  format  of  the  protocol  data  unit  (the  TC  Segment),  which  is 
implemented  within  the  Segmentation  layer.  Section  3.3  describes  the  procedures  used 
within  the  Segmentation  layer.  It  should  be  noted  that  the  Segmentation  layer  does  not 
include  a  telemetry  reporting  mechanism,  since  it  relies  on  closed-loop  procedures  performed 
within  the  Transfer  layer. 
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^  VC-0  VC-1  VC-2  *  *  *  VC-63^ 

V - - ^  ^ 

"VIRTUAL  CHANNELS"  PROVIDED  BY  THE  LAYER  BELOV\, 


Figure  3-1:  Orientation  of  the  Segmentation  Layer 
3.2  STANDARD  DATA  STRUCTURES  WITHIN  THE  LAYER 

3.2.1  TC  FRAME  DATA  UNIT 

The  TC  Frame  Data  Unit  is  the  data  unit  transferred  from  the  Segmentation  Layer  to  the 
Transfer  layer.  The  length  of  the  TC  Frame  Data  Unit  may  vary  from  one  TC  Frame  to  the 
next.  Its  length  shall  not  exceed  the  maximum  allowed  length  of  the  Transfer  Frame  Data 
Field. 

The  maximum  length  of  the  TC  Frame  Data  Unit  depends  on  whether  Frame  Error  Control  is 
being  used  (See  Section  4.2. 1.3). 

With  Frame  Error  Control  1017  octets 
Without  Frame  Error  Control  1019  octets 

The  maximum  length  allowed  by  a  particular  spacecraft  or  ground  system  implementation  on 
a  particular  Virtual  Channel  may  be  shorter  than  the  maximum  specified  here. 

The  content  of  a  TC  Frame  Data  Unit  is  defined  in  Section  3.3.1. 

3.2.2  TELECOMMAND  SEGMENT 

The  use  of  a  TC  Segment  is  required  for  any  Virtual  Channel  which  has  more  than  one  MAP 
or  which  transfers  TC  User  Data  Units  which  are  larger  than  permitted  in  a  single  TC  Frame. 
Its  use  is  optional  otherwise,  except  that  if  it  is  used  in  any  TC  Frame  carried  on  a  Virtual 
Channel,  it  must  be  used  for  all  TC  Frames  on  that  Virtual  Channel. 
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The  format  of  the  TC  Segment  is  shown  in  Figure  3-2. 


SEGMENT  HEADER - ► 


SEQUENCE 

MULTIPLEXER 

FLAGS 

ACCESS  POINT 

(MAP)  ID 

SEGMENT  DATA  FIELD 

2 

6 

1  OCTET  I  1018  OCTETS  (MAXIMUM) 


Figure  3-2:  Telecommand  Segment  Format 


3.2.2.1  Segment  Header.  The  Segment  Header  contains  the  following  two  fields: 


( 1 )  Sequence  Flags  (Bits  0, 1 ) 

This  two  bit  field  delimits  the  higher  layer  TC  User  Data  Unit  by  indicating  the 
sequential  position  of  the  TC  Segment  relative  to  the  TC  User  Data  Unit  (e.g.,  TC 
Packet)  of  which  the  TC  Segment  is  a  part.  The  flags  are  interpreted  as  follows: 


Bit  0  Bit  1 


Interpretation 


0 

0 

1 

1 


1  First  Segment  of  TC  User  Data  Unit  on  one  MAP 

0  Continuing  Segment  of  TC  User  Data  Unit  on  one  MAP 

0  Last  Segment  of  TC  User  Data  Unit  on  one  MAP 

1  No  segmentation  (one  TC  User  Data  Unit  or  multiple 

complete  TC  Packets) 


(2)  Multiplexer  Access  Point  (MAP)  Identifier  (Bits  2  through  7) 

The  MAP  facility  allows  user  command  data  from  different  sources  to  be 
multiplexed  together  so  that  they  share  the  communications  capacity  of  one 
Virtual  Channel,  thus  preventing  any  one  user  from  monopolizing  the  data 
transmission  resource. 


This  six-bit  field  enables  up  to  64  MAP  addresses  (from  MAP  0  to  MAP  63)  to  be 
associated  with  each  Virtual  Channel  provided  by  the  Transfer  layer.  Different 
TC  User  Data  Units  (e.g.,  separate  TC  Packets)  arriving  at  the  input  to  the 
Segmentation  layer  are  allocated  to  a  MAP.  The  segmentation  and  aggregation 
processes  are  conducted  independently  for  each  MAP.  The  resulting  TC  Frame 
Data  Units  from  up  to  64  MAPs  are  then  multiplexed  onto  one  Virtual  Channel  in 
accordance  with  user’s  delivery  priorities  and  instructions.  Certain  MAPs  may 
have  higher  transmission  priorities  than  others. 
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There  are  no  restrictions  on  the  selection  of  MAP  Identifiers.  In  particular,  MAPs 
are  not  required  to  be  numbered  consecutively. 

If  multiple  MAPs  are  not  used  on  a  particular  Virtual  Channel,  but  the  Segment 
Header  is  otherwise  required  to  be  present.  Bits  2  through  7  shall  be  set  to  a 
constant  value  for  all  TC  Segments  which  are  placed  on  that  Virtual  Channel. 

3.2.2.2  Segment  Data  Field.  The  Segment  Data  Field  contains  all  or  a  portion  of  the 
higher  layer  TC  User  Data  Unit  (e.g.,  TC  Packet)  or  an  aggregation  of  TC  Packets.  The 
Segment  Data  Field  length  is  variable  with  a  maximum  length  of  one  octet  less  that  the 
maximum  length  of  the  TC  Frame  Data  Unit. 

3.3  STANDARD  PROCEDURES  WITHIN  THE  LAYER 

Figure  3-3  illustrates  the  process  of  segmenting  and  aggregating  TC  User  Data  Units  (in  this 
example,  TC  Packets)  and  inserting  them  as  TC  Segments  into  TC  Frame  Data  Units.  The 
procedures  are  as  follows. 

3.3.1  SENDING  END  SEGMENTATION  PROCEDURES 

The  sending  end  of  the  Segmentation  layer  performs  the  following  processing  steps: 

(1)  Allocates  the  TC  User  Data  Unit  to  a  particular  Multiplexer  Access  Point. 

(2)  If  the  TC  User  Data  Unit  (e.g.,  the  TC  Packet)  exceeds  a  predetermined  length, 
the  Segmentation  layer  divides  it  into  portions  that  are  compatible  with  insertion 
into  the  TC  Frame  Data  Unit  and  attaches  a  Segment  Header  to  each  portion, 
forming  the  TC  Segment/Frame  Data  Unit.  If  the  TC  User  Data  Unit  is  a  TC 
Packet,  the  first  octet  of  the  TC  Packet  Primary  Header  shall  appear  in  the  leading 
octet  of  the  first  corresponding  Segment  Data  Field.  The  first  and  continuing 
Segments  may  each  have  a  length  equal  to  the  maximum  allowable  length  of  the 
TC  Frame  Data  Unit  on  that  particular  Virtual  Channel.  The  last  Segment  shall 
have  a  length  equal  to  the  residue  of  the  TC  User  Data  Unit  plus  the  Segmentation 
Header. 

(3)  If  aggregation  is  permitted  on  a  particular  MAP,  the  Segmentation  layer  places 
complete  TC  packets  into  the  TC  Segment  in  the  order  of  arrival.  If  Segment 
Headers  (and  hence  MAPs)  are  not  used  on  a  particular  Virtual  Channel,  but 
aggregation  is  permitted,  the  Segmentation  layer  places  the  TC  Packets  directly 
into  the  TC  Frame  Data  Unit.  In  either  case,  the  aggregated  packets  (plus 
Segment  Header,  if  used)  must  fit  within  the  maximum  size  TC  Frame  Data  Unit 
permitted  for  the  Virtual  Channel.  The  limitations  on  the  number  of  MAPs  which 
can  be  aggregating  TC  Packets  simultaneously  and  mechanisms  for  ensuring 
transmission  of  all  TC  Packets  are  implementation  dependent. 
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(4)  Multiplexes  together  the  TC  Frame  Data  Units  from  one  group  of  up  to  64  MAPs 
onto  one  Virtual  Channel,  according  to  the  mission’s  priority  scheme,  and  passes 
the  multiplexed  stream  to  the  layer  below. 

CAUTION 

A  TC  FRAME  DATA  UNIT  SHALL  CONSIST  OF  ONLY  ONE  OF  THE 
FOLLOWING: 

(a)  A  TC  SEGMENT  CONTAINING  A  PORTION  OF  ONE  TC  USER  DATA 
UNIT  (E.G.  A  PORTION  OF  ONE  TC  PACKET);  or 

(b)  A  TC  SEGMENT  CONTAINING  ONE  COMPLETE  TC  USER  DATA 
UNIT(E.G.,  ONE  COMPLETE  TC  PACKET);  or 

(c)  A  TC  SEGMENT  CONTAINING  MULTIPLE  COMPLETE  TC  PACKETS; 
or 

(d)  ONE  COMPLETE  TC  USER  DATA  UNIT  (E.G.,  ONE  COMPLETE  TC 
PACKET);  or 

(e)  MULTIPLE  COMPLETE  TC  PACKETS. 

TC  Packets  and  user-defined  data  units  may  not  be  intermixed.  Each  MAP  (if  Segment 
Headers  are  used)  or  Virtual  Channel  (if  Segment  Headers  are  not  used)  shall  carry  either  TC 
Packets  or  user-defined  data  units,  but  not  both. 

TC  Packets  with  different  destinations,  as  denoted  by  the  Application  Process  Identifier  in 
the  TC  Packet  Header,  may  be  carried  on  a  single  MAP  or  Virtual  Channel  and  may  be 
aggregated  within  a  single  TC  Frame  Data  Unit. 

Figure  3-3  shows  how  TC  Packets  assigned  to  one  MAP  are  aggregated  or  segmented  to  form 
TC  Segments/Frame  Data  Units. 
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Figure  3-3:  Example  of  the  Segmentation  Procedure 


3.3.2  RECEIVING  END  SEGMENTATION  PROCEDURES 

The  receiving  end  of  the  TC  Segmentation  layer  performs  the  following  processing  steps: 

(1)  Accepts  a  stream  of  multiplexed  TC  Segments/Frame  Data  Units  on  one  Virtual 
Channel  from  the  Transfer  layer. 

(2)  Sorts  these  Segments  according  to  the  MAP  IDs  which  appear  in  their  Segment 
Headers. 

(3)  a.  For  TC  Frame  Data  Units  containing  a  segment  of  a  TC  User  Data  Unit: 

reassembles  the  Segments  (less  headers)  for  each  MAP,  using  the  Sequence  Flags, 
in  order  to  recreate  the  original  TC  User  Data  Unit. 

b.  For  all  other  TC  Frame  Data  Units:  extracts  the  TC  Packets  or  TC  User  Data 
Unit,  using  the  Frame  and  Packet  Length  fields. 

(4)  Passes  the  resulting  TC  User  Data  Unit(s)  to  the  layer  above. 
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4  TRANSFER  LAYER:  STANDARD  DATA  STRUCTURES  AND 
PROCEDURES 

4.1  OVERVIEW  OF  THE  LAYER 

The  TC  Transfer  layer  is  the  “heart”  of  the  standard  conventional  TC  System.  It  is  this  layer 
which  takes  care  of  most  of  the  operations  required  to  move  sets  of  user  TC  data  reliably 
from  the  sending  end  of  the  system  to  the  receiving  end  in  space. 

Section  4.2  defines  the  format  of  the  two  standard  data  structures  that  reside  within  the  layer: 
the  “TC  Transfer  Frame”,  which  flows  from  the  sending  end  of  the  TC  System  to  its 
receiving  end,  and  the  “Command  Link  Control  Word”  (CLCW),  which  is  formatted  by  the 
receiving  end  and  is  transmitted  back  to  the  sending  end  via  corresponding  layers  within  the 
Telemetry  System. 

Section  4.3  defines  the  standard  procedures  which  are  associated  with  the  layer: 

-  Frame  Delimiting  and  Fill  Removal  Procedure 

-  Frame  Validation  Check  Procedure 

-  Command  Operation  Procedure  (COP) 

A  COP  consists  of  a  pair  of  synchronized  procedures  which  execute  within  one  TC  Virtual 
Channel  (VC)  at  the  sending  and  receiving  ends  of  the  layer.  At  the  sending  end  a  “Frame 
Operation  Procedure”  (FOP)  is  executed.  At  the  receiving  end  a  corresponding  spacecraft 
“Frame  Acceptance  and  Reporting  Mechanism”  (FARM)  is  executed.  Detail  specification  of 
the  COPs  are  contained  in  Reference  [7]. 

Only  one  COP  is  defined  in  this  Recommendation:  COP-1. 

The  orientation  of  these  elements  within  the  Transfer  layer  is  shown  in  Figure  4-1. 


4.2  STANDARD  DATA  STRUCTURES  WITHIN  THE  LAYER 

This  section  describes  the  formats  of  the  following  two  standard  protocol  data  units  which 
reside  within  the  TC  Transfer  layer: 

(1)  The  TC  Transfer  Frame,  which  is  the  data  structure  that  is  “uplinked”  to  the 
receiving  end  of  the  layer  on  the  spacecraft. 

(2)  The  TC  Command  Link  Control  Word  (CLCW),  which  is  the  data  structure  that  is 
“downlinked”  by  the  spacecraft  back  to  the  sending  end  of  the  layer  in  order  to 
provide  reports  which  describe  the  status  of  acceptance  and  reassembly  of  TC 
Frames. 
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(MULTIPLE  “VIRTUAL”  CHANNELS  PROVIDED  TO  THE  LAYER  ABOVE) 


(TC  SENDING 
END) 


(TC  RECEIVING 
END) 


(SINGLE  PHYSICAL  CHANNEL  PROVIDED  BY  THE  LAYER  BELOW) 


Figure  4-1:  Orientation  of  the  Transfer  Layer 
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4.2.1  TC  TRANSFER  FRAME  FORMAT 

The  TC  Frame  (Figure  4-2)  contains  the  following  major  fields: 

Major  Field  Length  (Octets) 

FRAME  HEADER  5 

FRAME  DATA  FIELD  Variable  (up  to  1019) 

FRAME  ERROR  CONTROL  (Optional)  (2) 

1024  octets  (maximum) 

The  maximum  TC  Frame  length  allowed  by  a  particular  spacecraft  or  ground  implementation 
on  a  particular  Virtual  Channel  may  be  less  than  the  maximum  specified  here. 


•  FRAME  HEADER  (5  octets)  • 


2  octets 


2  octets 


1  octet 


CC- 


VERSION 

BYPASS 

CONTROL 

S 

SPACE 

VIRTUAL 

FRAME 

FRAME 

— 

FRAME 

FRAME 

NUMBER 

FLAG 

COMMAND 

P 

CRAFT 

CHANNEL 

LENGTH 

SEQUENCE 

DATA 

ERROR 

FLAG 

A 

ID 

ID 

NUMBER 

FIELD 

CONTROL 

R 

E 

(opt) 

2 

1 

1 

2 

10 

6 

10 

8 

SC- 

(16) 

1019 

octets 

(max) 


Figure  4-2:  TC  Transfer  Frame  Format 


4.2.1. 1  Transfer  Frame  Header.  The  FRAME  HEADER  of  the  TC  Transfer  Frame 
consists  of  the  following  fields,  grouped  into  octets  as  shown: 


Field 

#Bits 

#Octets 

Version  Number 

2 

Bypass  Flag 

1 

Control  Command  Flag 

1 

Reserved  Spares 

2 

Spacecraft  ID 

10 

2 

Virtual  Channel  ID 

6 

Frame  Length 

10 

2 

Frame  Sequence  Number 

8 

1 

5  octets 
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The  first  two  octets  of  the  FRAME  HEADER  contain  the  following  field  allocations: 

(1)  VERSION  NUMBER  (Bits  0,1) 

The  VERSION  NUMBER  occupies  the  two  most  significant  bits  of  the  Frame 
Header.  Future  changes  in  the  TC  Transfer  Frame  structure  may  be 
accommodated  by  changing  the  VERSION  NUMBER.  At  present,  only  Version 
“1”  of  the  TC  Transfer  Frame  (the  format  specified  herein)  is  defined.  It  shall  be 
identified  by  setting  Bits  0,1  to  value  “00”. 

(2)  BYPASS  FLAG  (Bit  2) 

The  single-bit  BYPASS  FLAG  controls  the  application  of  “Frame  Acceptance 
Checks”  by  the  receiving  spacecraft.  ALL  Frames  received  by  the  spacecraft  first 
undergo  a  basic  standard  set  of  “Frame  Validation  Checks”,  which  are  applied 
regardless  of  the  setting  of  the  BYPASS  FLAG. 

The  Frame  Acceptance  and  Reporting  Mechanism  (FARM)  associated  with  the 
COP  can  be  made  to  operate  in  a  normal  “Acceptance”  (frame  “Type-A”)  mode 
or  a  “Bypass”  (frame  “Type-B”)  mode,  according  to  the  setting  of  the  BYPASS 
FLAG. 

Setting  Bit  2  to  value  “0”  specifies  a  Type-A  TC  Frame;  acceptance  of  this  Type 
of  frame  by  the  spacecraft  shall  be  subject  to  the  normal  frame  acceptance  checks 
of  the  FARM. 

Setting  Bit  2  to  value  “1”  specifies  a  Type-B  TC  Frame;  the  normal  frame 
acceptance  checks  of  the  FARM  shall  be  bypassed. 

Necessarily,  it  must  be  possible  to  send  Type-A  and  Type-B  TC  Frames  on  the 
same  TC  Virtual  Channel  in  order  to  conduct  some  operations. 

(3)  CONTROL  COMMAND  FLAG  (Bit  3) 

The  CONTROL  COMMAND  FLAG  specifies  whether  the  data  field  of  the  TC 
Transfer  Frame  is  conveying  transfer  “Control  Commands”  (the  “C”  mode),  or 
“Data”  (the  “D”  mode). 

In  the  “C”  mode  the  Frame  Data  Field  contains  control  information  which  is  used 
to  set  the  parameters  of  the  FARM  to  the  proper  configuration  to  accept 
telecommand  data. 

In  the  “D”  mode  the  Frame  Data  Field  contains  a  Frame  Data  Unit  (e.g.,  a  TC 
Packet  or  a  TC  Segment). 

Setting  Bit  3  to  value  “0”  indicates  the  “D”  mode  to  the  receiving  spacecraft,  i.e., 
that  the  Frame  Data  Field  contains  data. 
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Setting  Bit  3  to  value  “1”  indicates  the  “C”  mode  to  the  receiving  spacecraft,  i.e., 
that  the  Frame  Data  Field  contains  Control  Commands.  The  combined  states  of 
the  BYPASS  FLAG  and  the  CONTROL  COMMAND  FLAG  are  interpreted  by 
the  receiving  spacecraft  as  shown  in  Table  4-1. 


Table  4-1:  Interpretation  of  the  “Bypass”  and  “Control  Command”  Flags 


Bypass  Flag 

Control  Command  Flag 

Interpretation 

0 

0 

Type-AD.  Frame  Data  Field  carries  TC  data 
(e.g..  Packets  or  Segments),  subject  to 
acceptance  check  under  control  of  the  FARM. 
These  Frames  use  the  Sequence-Controlled  (or 
AD)  Service  of  the  COP. 

0 

1 

Reserved  for  future  application. 

1 

0 

Type-BD.  Frame  Data  Field  carries  TC  data 
(e.g..  Packets  or  Segments),  with  all  frame 
acceptance  checks  bypassed  under  control  of 
the  FARM.  These  Frames  use  the  Expedited 
(or  BD)  Service  of  the  COP. 

1 

1 

Type-BC.  Frame  Data  Field  carries  FARM 
Control  Commands,  with  all  frame  acceptance 
checks  bypassed  under  control  of  the  FARM. 
These  Frames  control  the  Sequence- 
Controlled  Service  of  the  COP. 

(4)  RESERVED  SPARES  (Bits  4,5) 

These  two  bits  are  reserved  for  future  application.  At  present.  Bits  4,5  shall  be  set 
to  value  “00”. 

(5)  SPACECRAFT  IDENTIFIER  (Bits  6  through  15) 

These  ten  bits  carry  the  identification  code  for  the  spacecraft  being  commanded. 
The  Secretariat  of  the  CCSDS  assigns  the  SPACECRAFT  IDENTIFIER  to  each 
vehicle  within  a  particular  mission  as  defined  in  Reference  [10]. 
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The  third  and  fourth  octets  of  the  FRAME  HEADER  contain  the  following  field  allocations: 

(6)  VIRTUAL  CHANNEL  IDENTIFIER  (Bits  16  through  21) 

As  described  in  Section  3,  the  Transfer  layer  provides  a  “Virtual  Channel”  service 
to  the  Segmentation  layer.  Beneath  the  Transfer  layer  is  the  single  physical 
telecommand  data  channel  which  is  provided  by  the  Channel  Service  (Reference 
[4]).  The  Virtual  Channel  facility  allows  this  single  physical  channel  to  be 
logically  multiplexed,  on  a  frame-by-frame  basis,  so  that  its  transmission  capacity 
may  be  shared. 

Every  TC  Transfer  Frame  shall  have  a  6-bit  VIRTUAL  CHANNEL  ID  field 
present  in  the  Frame  Header.  Each  state  of  the  identifier  creates  one  Virtual 
Channel,  from  VC  0  to  VC  63,  so  that  up  to  64  different  logical  paths  may  be 
defined  through  the  single  physical  channel.  The  Transfer  layer  may  therefore 
present  up  to  64  Virtual  Channels  to  the  Segmentation  layer. 

Each  Virtual  Channel  may  also  have  up  to  64  Multiplexer  Access  Points  (MAPs) 
attached  to  it  by  the  Segmentation  layer  for  the  purpose  of  multiplexing  user  data 
together. 


NOTE 

If  multiplexing  is  not  performed  in  the  Segmentation  layer  (i.e.,  if  only  one 
MAP  is  activated  per  Virtual  Channel)  or  if  the  Segment  Header  is  omitted 
for  a  particular  mission,  then  the  Virtual  Channel  feature  of  the  Transfer 
layer  provides  an  alternative  method  for  multiplexing  user  data  onto  the 
physical  channel.  Using  this  feature  of  the  Transfer  layer,  up  to  64 
concurrent  users  may  be  multiplexed  together  by  attaching  each  to  its  own 
dedicated  Virtual  Channel  during  transfer  through  the  physical  channel. 
However,  since  every  open  Virtual  Channel  has  its  own  CLCW  reporting 
scheme.  Virtual  Channel  multiplexing  may  increase  the  spacecraft  reporting 
complexity. 

The  internal  partitioning  and  use  of  the  Virtual  Channel  field  is  mission-specified; 
e.g.,  some  of  the  bits  may  be  allocated  by  a  mission  to  form  a  “Spacecraft  Sub- 
ID”,  which  allows  different  spacecraft  data  handling  chains  to  be  addressed. 

(7)  FRAME  LENGTH  (Bits  22  through  3 1 ) 

This  10-bit  field  contains  a  length  count  “C”  which  equals  one  fewer  than  the  total 
octets  in  the  TC  Transfer  Frame.  The  count  is  measured  from  the  first  bit  of  the 
FRAME  HEADER  to  the  last  bit  of  the  FRAME  ERROR  CONTROL  FIELD  (if 
present),  or  the  last  bit  of  the  FRAME  DATA  FIELD  if  the  error  control  is 
omitted.  The  size  of  this  field  limits  the  maximum  length  of  a  TC  Transfer  Frame 
to  1024  octets.  The  length  count  “C”  is  expressed  as: 

“C”  =  (Total  Number  of  Octets)  - 1 
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The  fifth  octet  of  the  FRAME  HEADER  contains  the  following  field: 

(8)  FRAME  SEQUENCE  NUMBER  (Bits  32  through  39) 

The  FRAME  SEQUENCE  NUMBER,  which  within  this  Recommendation  is 
denoted  as  N(S),  is  an  up-counting  binary  number  which  is  assigned  to  each  TC 
Frame  by  the  TC  Transfer  layer,  and  which  remains  a  viable  entity  only  within 
this  layer. 

The  FRAME  SEQUENCE  NUMBER  enables  the  FARM  to  check  the 
sequentiality  of  incoming  Type-A  TC  Frames.  The  8-bit  FRAME  SEQUENCE 
NUMBER  field  supports  a  modulo-256  sequence  count. 

The  FRAME  SEQUENCE  NUMBER  is  Virtual  Channel  dependent;  i.e.,  the 
Transfer  layer  shall  maintain  a  separate  FRAME  SEQUENCE  NUMBER  for  each 
of  the  (up  to  64)  VIRTUAL  CHANNELS. 

Note  that  the  COP  does  not  use  this  field  when  operating  with  Type-B  TC  Frames;  in  this 
case  the  contents  of  the  FRAME  SEQUENCE  NUMBER  field  shall  be  set  to  “all  zeros”. 

4.2.1.2  Transfer  Frame  Data  Field.  The  FRAME  DATA  FIELD,  which  is  of 

variable  length  up  to  a  maximum  of  1019  octets  (1017  octets  if  the  FRAME  ERROR 
CONTROL  FIELD  is  present),  shall  contain  either  an  integral  number  of  octets  of 
teleconunand  data  corresponding  to  one  TC  Frame  Data  Unit  or  an  integral  number  of  octets 
of  Control  Command  information.  The  FRAME  DATA  FIELD  shall  be  inserted  directly 
after  the  Frame  Header  with  no  filler  between. 

4.2.1.2.1  TC  Frame  Data  Unit.  The  TC  Frame  Data  Unit  is  supplied  by  the  Segmentation 
layer.  The  content  of  a  TC  Frame  Data  Unit  is  defined  in  Section  3.3.1. 

4.2.1. 2.2  Control  Commands.  There  are  two  Control  Commands  defined:  UNLOCK  and 
SET  V(R).  The  action  to  be  taken  when  the  FARM  receives  one  of  the  Control  Commands  is 
defined  in  Reference  [7].  All  other  bit  combinations  for  Control  Commands  are  reserved  by 
the  CCSDS  for  future  application. 

UNLOCK:  The  UNLOCK  Control  Command  consists  of  a  single  octet  containing 
“all  zeroes”. 

SET  V(R):  The  SET  V(R)  Control  Command  consists  of  three  octets  with  the 
following  values: 

10000010  00000000  XXXXXXXX 

where  XXXXXXXX  is  the  value  to  which  the  FARM  should  set  V(R),  the 
Receiver_Frame_Sequence_Number.  This  octet  should  therefore  be  set  to  the 
Sequence  Number  which  will  be  put  into  the  Header  of  the  next  Type-A  TC  Frame  to 
be  transmitted  on  that  Virtual  Channel. 
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4.2.1.3  Transfer  Frame  Error  Control  Field.  The  purpose  of  this  optional  16-hit  field 
(which  occupies  the  two  trailing  octets  of  the  TC  Frame)  is  to  provide  frame  error  control 
information.  The  Frame  Error  Control  Field  is  used  only  for  error  detection,  but  it  is 
particularly  useful  when  project  requirements  dictate  an  undetected  frame  error  performance 
that  exceeds  the  inherent  performance  provided  by  the  underlying  Channel  Service. 
Performance  information  is  found  in  Annex  B  and  Reference  [2].  If  used,  the  preferred  error 
control  technique  is  the  Cyclic  Redundancy  Check  (CRC)  described  in  the  following 
sections. 


4.2.1.3.1  Encoding  Procedure.  The  encoding  procedure  accepts  a  Transfer  Frame, 
excluding  the  Frame  Error  Control  Field,  and  generates  a  systematic  binary  block  code  by 
appending  a  16-bit  Frame  Error  Control  Word  (FECW)  as  the  final  16  bits  of  the  codeblock. 

The  equation  for  the  FECW  is: 

FECW  =  [(Xl6  •  M(X))  +  (X(n-16)  •  L(X))]  modulo  G(X) 

where  all  arithmetic  is  modulo  2 

M(X)  =  the  (n-16)-bit  message  to  be  encoded  expressed  as  a  polynomial 
with  binary  coefficients 

L(X)  =  the  presetting  polynomial  given  by: 

15 

L(X)  =  XX‘ 

i=0 

(i.e.,  all  “1”  polynomial  of  order  15) 

G(X)  =  the  generating  polynomial  given  by: 

G(X)  =  x16  -I-X12  +x5-h  1 

n  =  the  number  of  bits  in  the  encoded  message 

The  X(^'16)  •  L(X)  term  has  the  effect  of  presetting  the  shift  register  to  an  all 
“1”  state  prior  to  encoding. 

A  possible  implementation  of  an  encoder  is  described  in  Reference  [2]. 
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4.2.1.3.2  Decoding  Procedure.  The  entire  TC  Frame,  including  the  Frame  Error 
Control  field  is  provided  to  the  decoder. 

The  error  detection  syndrome,  S(X),  is  given  by 

S(X)  =  [(Xl6  •  C*(X))  +  (Xn  •  L(X))]  modulo  G(X) 

where  C*(X)  =  the  received  block  in  polynomial  form 

S(X)  =  the  syndrome  polynomial,  which  will  be  zero  if  no  error  is 
detected  and  non-zero  if  an  error  is  detected. 

A  possible  implementation  of  a  decoder  is  contained  in  Reference  [2]. 

4.2.2  COMMAND  LINK  CONTROL  WORD  (CLCW)  FORMAT 

The  CLCW,  which  is  a  four-octet  word  that  is  conveyed  in  the  Operational  Control  Field  of  a 
CCSDS  Telemetry  Transfer  Frame  (Reference  [5])  or  Virtual  Channel  Data  Unit  (VCDU) 
(Reference  [8]),  provides  the  mechanism  by  which  the  FARM  reports  the  status  of  frame 
acceptance  to  the  Frame  Operation  Procedure  (FOP)  at  the  sending  end  of  the  Transfer  layer. 

NOTE 

The  controlling  specification  for  how  the  CLCW  is  used  within  the  COP  is  contained 
in  Reference  [7]. 

The  CLCW  is  the  only  reporting  mechanism  for  the  TC  Transfer  layer.  Although  it  is  not 
necessary  that  the  Telemetry  reporting  rate  match  the  Telecommand  transfer  rate,  some 
minimum  CLCW  sampling  rate  is  necessary  for  the  proper  operation  of  the  COP. 

The  format  of  the  CLCW  is  shown  in  Figure  4-3. 
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CONTROL 
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2 
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NO 
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8 

Figure  4-3:  Command  Link  Control  Word  Format 

The  CLCW  contains  the  following  fields: 

Field  Length  (Bits) 


CONTROL  WORD  TYPE 
CLCW  VERSION 
STATUS  FIELD 
COP  IN  EFFECT 
VIRTUAL  CHANNEL  ID 
RESERVED  SPARE 


FLAGS: 

-  No  rf  available  (1) 

-No  bit  lock  (1) 

-Lockout  (1) 

-  Wait  (1) 

-  Retransmit  (1) 


FARM  B  COUNTER 
RESERVED  SPARE 
REPORT  VALUE 


1 

2 

3 

2 

6 

2 

5 


2 

1 

8_ 

32  bits  (4  octets) 
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Unless  otherwise  stated,  all  fields  are  required  elements. 

(1 )  CONTROL  WORD  TYPE  (Bit  0) 

This  one-bit  field  shall  be  set  to  zero  to  indicate  that  the  Operational  Control  Field 
contains  a  CLCW. 

(2)  CLCW  VERSION  NUMBER  (Bits  1 ,2) 

The  two-bit  CLCW  VERSION  NUMBER  field  is  included  to  provide  future  growth 
flexibility.  However,  at  present  a  single  “Version- 1”  CLCW  format  is  defined  in 
this  Recommendation.  It  shall  be  indicated  by  setting  Bits  1,2  to  value  “00”.  The 
format  of  the  Version-1  CLCW  report  is  described  herein. 

(3)  STATUS  FIELD  (Bits  3,4,5) 

Application  of  this  field  is  mission-specified.  It  may  be  used  by  Agencies  or 
Centers  for  local  enhancements  to  TC  operations  and  is  not  part  of  the  COP 
protocol. 

(4)  COP  IN  EFFECT  (Bits  6,7) 

These  two  bits  indicate  the  COP  which  is  being  used.  At  present  a  single  COP, 
COP-1,  is  defined.  It  shall  be  identified  by  setting  Bits  6,7  to  the  binary  value  “01”. 

(5)  VIRTUAL  CHANNEL  ID  (Bits  8-13) 

This  field  contains  the  VIRTUAL  CHANNEL  Identifier  of  the  TC  Virtual  Channel 
with  which  this  report  is  associated.  Each  Virtual  Channel  which  is  open  shall  have 
its  own  CLCW  reporting  activated. 

(6)  RESERVED  SPARES  (Bits  14, 1 5) 

These  two  bits  are  reserved  by  CCSDS  for  future  application.  For  the  present.  Bits 
14,15  shall  be  set  to  value  “00”. 

(7)  FLAGS  (Bits  16,17,18,19,20) 

(a)  NO  RF  AVAILABLE  flag  (Bit  16) 

The  NO  RF  AVAILABLE  flag  provides  a  logical  indication  of  the  “ready” 
status  of  the  radio  frequency  (rf)  elements  within  the  physical  data  channel 
provided  by  the  Channel  Service  layers.  Precise  definition  of  the  set  of 
physical  states  which  must  each  be  in  the  “ready”  condition  before 
commanding  is  possible  is  mission-specified.  For  example,  the  flag  can 
represent  a  logical  sum  of  the  overall  ready  status  of  components  such  as  the 
rf  transponder  and  the  demodulator. 
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Whenever  Bit  16  is  set  to  value  “0”,  the  physical  channel  is  AVAILABLE 
(i.e.,  any  TC  Transfer  Frame  will  be  received  and  processed  by  the  Channel 
Service  layers  and  passed  on  to  the  Transfer  layer  if  correct). 

Whenever  Bit  16  is  set  to  value  “1”,  the  physical  channel  is  NOT 
AVAILABLE  and  TC  Transfer  Frames  cannot  be  transferred  without 
corrective  action  within  the  Channel  Service  layers. 

The  single  NO  RF  AVAILABLE  flag  applies  to  all  Virtual  Channels.  This 
input  parameter  to  the  CLCW  is  updated  whenever  a  change  is  signaled  by  the 
Channel  Service. 

(b)  NO  BIT  LOCK  flag  (Bit  17) 

The  NO  BIT  LOCK  flag  is  an  optional,  mission-specific  engineering 
measurement  which  provides  a  performance  quality  indicator  that  indicates 
specifically  whether  the  Channel  Service  layers  are  working  normally  by 
having  enough  signal  energy  to  achieve  bit  synchronization  with  the  received 
data  stream.  If  bit  lock  is  not  achieved,  this  may  indicate  that  the  Channel 
Service  layers  are  operating  at  a  non-nominal  performance  level  and  that  the 
TC  Frame  rejection  rate  may  be  correspondingly  abnormally  high. 

When  Bit  17  is  used  and  set  to  value  “0”,  this  indicates  BIT  LOCK 
ACHIEVED.  When  Bit  17  is  used  and  set  to  value  “1”,  this  indicates  NO  BIT 
LOCK  ACHIEVED. 

This  flag  is  not  part  of  the  COP  protocol,  and  may  therefore  be  used  by 
Agencies  or  Centers  for  local  enhancements  to  TC  operations.  If  not  used,  it 
shall  be  set  permanently  to  value  “0”. 

The  single  NO  BIT  LOCK  flag  applies  to  all  Virtual  Channels.  This  input 
parameter  to  the  CLCW  is  updated  whenever  a  change  is  signaled  by  the 
Channel  Service. 

(c)  LOCKOUT  flag  (Bit  1 8) 

Bit  18  is  set  to  value  “1”  to  indicate  LOCKOUT  whenever  a  Type-A  TC 
Frame  is  received  on  a  particular  Virtual  Channel  which  violates  certain  frame 
acceptance  checks.  Once  the  FARM  is  in  LOCKOUT,  all  subsequent  Type-A 
TC  Frames  are  rejected  by  that  FARM  until  the  condition  is  cleared.  The 
conditions  for  entering  and  exiting  LOCKOUT  for  the  COP  are  specified  in 
Reference  [7].  If  the  FARM  is  not  in  LOCKOUT,  Bit  18  shall  be  set  to  value 
“0”. 


Necessarily,  separate  LOCKOUT  flags  shall  be  maintained  for  each  Virtual 
Channel. 
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(d)  WAIT  flag  (Bit  19) 

When  Bit  19  is  set  to  value  “1”,  this  indicates  that  the  receiving  end  of  the 
Transfer  layer  is  unable  to  pass  data  to  the  Segmentation  layer  on  a  particular 
Virtual  Channel.  This  may  be  caused  by  temporary  lack  of  storage  and/or 
processing  resources  in  the  receiving  end  of  the  Transfer  or  higher  layers. 

When  Bit  19  is  set  to  value  “1”  (i.e.,  WAIT)  for  a  particular  Virtual  Channel, 
all  further  Type-A  TC  Frames  on  that  channel  shall  be  rejected  by  the  FARM 
until  the  condition  is  cleared  by  freeing  the  congestion,  either  automatically  or 
by  taking  appropriate  control  action  as  defined  in  Reference  [7]. 

When  Bit  19  is  set  to  value  “0”  (i.e.,  DON’T  WAIT),  normal  Type-A 
commanding  may  proceed  on  that  channel. 

The  precise  specifications  for  use  of  the  WAIT  Flag  are  contained  in 
Reference  [7].  Necessarily,  separate  WAIT  flags  shall  be  maintained  for  each 
Virtual  Channel. 

(e)  RETRANSMIT  Flag  (Bit  20) 

The  RETRANSMIT  flag  speeds  the  operation  of  the  COP  by  providing 
immediate  indication  (Bit  20  set  to  value  “1”)  to  the  FOP  at  the  sending  end 
that  one  or  more  Type-A  frames  on  a  particular  TC  Virtual  Channel  have  been 
rejected  or  found  missing  by  the  FARM  and  therefore  retransmission  is 
required.  The  conditions  which  cause  the  flag  to  be  set  are  specified  in 
Reference  [7]. 

When  Bit  20  is  set  to  value  “0”,  this  indicates  that  there  are  no  outstanding 
Type-A  frame  rejections  in  the  sequence  received  so  far,  and  thus 
retransmissions  are  not  required. 

The  precise  specifications  for  use  of  the  RETRANSMIT  Flag  are  contained  in 
Reference  [7].  Necessarily,  separate  RETRANSMIT  flags  shall  be  maintained 
for  each  Virtual  Channel. 

(8)  FARM-B  COUNTER  (Bits  21 ,22) 

This  field  contains  the  two  least  significant  bits  of  a  FARM-B  COUNTER.  This 
counter  is  maintained  within  the  FARM  and  increments  once  each  time  a  Type-B 
TC  Transfer  Frame  is  accepted  in  BYPASS  mode  on  a  particular  Virtual  Channel. 
The  field  supports  the  verification  that  BYPASS  mode  frames  (Control  or  user 
Data)  were  accepted  by  the  spacecraft. 

Necessarily,  separate  FARM-B  COUNTERS  shall  be  maintained  for  each  Virtual 
Channel. 
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(9)  RESERVED  SPARE  (Bit  23) 

This  bit  is  reserved  by  CCSDS  for  future  application.  For  the  present,  Bit  23  shall 
be  set  to  value  “0”. 

(10)  REPORT  VALUE  (Bits  24-31) 

This  field,  which  shall  always  be  one  octet  long,  contains  the  value  of  “N(R)”,  i.e., 
the  current  observed  value  of  the  FARM’S  NEXT  EXPECTED  FRAME 
SEQUENCE  NUMBER  V(R).  The  FARM  V(R)  counter  shall  increment  once  each 
time  a  Type-AD  TC  Frame  is  accepted  on  a  particular  Virtual  Channel. 

The  precise  specifications  for  use  of  the  REPORT  VALUE  are  contained  in 
Reference  [7].  Necessarily,  separate  counters  shall  be  maintained  for  each  Virtual 
Channel. 

4.3  STANDARD  PROCEDURES  WITHIN  THE  LAYER 

Standard  procedures  within  the  Transfer  layer  are  concerned  with  the  following  operations: 

(1)  At  the  receiving  end  of  the  system,  reconstituting  TC  Frames  from  the  data  stream 
provided  by  the  Channel  Service  Coding  layer  and  removing  any  Fill  Data 
transferred  from  that  layer. 

(2)  At  the  receiving  end  of  the  system,  performing  standard  “Frame  Validation 
Checks”  on  all  TC  Frames  reconstituted  from  the  Coding  layer. 

(3)  At  both  ends  of  the  system,  executing  the  Command  Operation  Procedure  which 
is  used  to  move  TC  Frames  across  the  Transfer  layer,  including  performing  frame 
acceptance  checks  and  establishing  and  using  various  counters,  numbers  and 
windows. 

4.3.1  FRAME  DELIMITING  AND  FILL  REMOVAL  PROCEDURE 

The  Telecoimnand  Channel  Service  (Reference  [4])  resides  immediately  below  the  Transfer 
layer.  At  the  sending  end  of  the  TC  System,  the  Transfer  layer  passes  one  or  more  TC 
Frames  to  the  Channel  Service  Coding  layer,  which  encodes  the  frames  to  protect  them  from 
errors  which  may  be  introduced  as  they  are  transmitted  through  the  physical  channel.  Fill 
Data  may  have  to  be  inserted  by  the  Channel  Service  to  ensure  correct  transmission  of  all 
valid  data. 

The  receiving  end  of  the  Transfer  layer  receives  as  an  input  from  the  Coding  layer  a  series  of 
data  octets,  corresponding  to  the  decoded  frame(s),  which  have  been  declared  “clean”  by  the 
Coding  layer  insofar  as  they  contain  no  detected  errors.  The  Coding  layer  provides  a  “Data 
Start”  signal  to  the  Transfer  layer,  indicating  that  data  are  being  transferred. 

The  Data  Start  signal  shall  be  set  TRUE  while  the  Coding  layer  is  in  the  process  of  actively 
transferring  data  octets.  Since  the  first  octet  transferred  after  Data  Start  goes  TRUE 
corresponds  to  the  first  octet  of  the  first  TC  Transfer  Frame,  the  receiving  end  of  the  Transfer 
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layer  may  delimit  this  frame — and  each  of  any  successive  TC  Transfer  Frames — ^by  reading 
the  FRAME  LENGTH  field  in  the  first  header,  and  then  successively  reading  the  FRAME 
LENGTH  field  in  each  subsequent  header. 

The  Data  Start  signal  shall  become  FALSE  (indicating  “Data  Stop”)  when  the  Coding  layer 
stops  transferring  octets  because  of  a  decoder  failure  or  channel  deactivation.  Decoding 
failure  may  be  caused  by  the  normal  end  of  the  transmitted  TC  Frame(s),  or  by  a  genuine 
channel-induced  error. 

If  one  or  more  valid  FRAME  LENGTH  fields  are  detected  by  the  receiving  end  of  the 
Transfer  layer  and  the  number  of  octets  received  when  the  Data  Stop  condition  occurs  equals 
the  number  of  octets  specified  by  the  FRAME  LENGTH(s),  then  each  Frame  shall  be  passed 
on  to  the  Frame  Validation  Check  procedure  (see  4.3.2)  as  it  is  delimited. 

If  a  valid  FRAME  LENGTH  field  is  detected  by  the  receiving  end  of  the  Transfer  layer  but 
the  number  of  octets  received  when  the  Data  Stop  condition  occurs  is  less  than  the  number  of 
octets  specified  by  that  FRAME  LENGTH,  this  entire  Frame  shall  be  discarded  since  this 
indicates  that  a  failure  has  occurred,  possibly  due  to  a  ehannel  error  detected  during  reception 
of  the  data  stream  within  the  Channel  Service  layers  below. 

If  a  valid  FRAME  LENGTH  field  is  detected  by  the  receiving  end  of  the  Transfer  layer  but 
the  number  of  octets  received  when  the  Data  Stop  condition  occurs  is  greater  than  the  number 
of  octets  specified  by  that  FRAME  LENGTH,  Fill  Data  was  probably  appended  by  the 
sending  end  Coding  layer  to  complete  the  last  TC  Codeblock  (Reference  [4]).  Because  the 
receiving  end  Coding  layer  cannot  distinguish  between  valid  data  and  Fill  Data,  the  Fill  Data 
must  be  stripped  by  the  Transfer  layer. 

The  characteristics  of  the  present  TC  Codeblock  structure  are  such  that  no  more  than  six 
octets  of  Fill  Data  can  occur.  If  LESS  THAN  FIVE  trailing  octets  of  Fill  Data  are  present, 
then  they  cannot  possibly  form  a  Frame  Header,  and  they  will  be  immediately  discarded  by 
the  Transfer  layer.  If  FIVE  OR  SIX  trailing  octets  of  Fill  Data  exist,  the  Transfer  layer  data 
handling  process  might  attempt  to  interpret  the  Fill  Data  as  a  new  Transfer  Frame  Header; 
however,  the  subsequent  Frame  Validation  Check  (see  4.3.2)  will  prevent  this  from 
happening  because  the  Fill  pattern  of  “01010101”  appearing  in  each  octet  will  violate  at  least 
one  of  the  validation  tests;  in  particular,  this  pattern  appearing  where  the  FRAME  LENGTH 
field  might  be  expected  will  indicate  a  frame  length  that  exceeds  the  number  of  octets 
received  from  the  Coding  layer,  thus  failing  a  test  and  causing  the  trailing  five  or  six  octets  to 
be  discarded. 

4.3.2  FRAME  VALIDATION  CHECK  PROCEDURE 

After  each  TC  Transfer  Frame  is  reconstituted  from  the  string  of  octets  provided  by  the 
Coding  layer,  it  will  next  be  subjected  to  a  set  of  standard  tests  called  a  “Frame  Validation 
Check”.  The  Frame  Validation  Check  shall  be  applied  to  ALL  incoming  TC  Transfer 
Frames,  regardless  of  whether  they  are  Type-A  or  Type-B.  Failure  to  pass  any  test  within  the 
Frame  Validation  Check  shall  cause  the  Transfer  Frame  to  be  rejected  (discarded).  The 
Frame  Validation  Check  consists  of  the  following  tests: 
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(1)  The  TC  Frame  must  have  an  expected  VERSION  NUMBER. 

(2)  The  TC  Frame  must  have  the  expected  SPACECRAFT  ID. 

(3)  The  TC  Frame  Header  must  not  contain  any  values  which  are  not  consistent  with 
the  implemented  features  for  that  spacecraft. 

(4)  The  value  of  the  FRAME  LENGTH  must  be  consistent  with  the  number  of  octets 
that  are  present. 

(5)  If  implemented,  the  FRAME  ERROR  CONTROL  test  must  pass. 

(6)  The  Data  Field  of  a  TC  Frame  containing  a  Control  Command  must  be  consistent 
with  the  allowed  Control  Conunands. 


4.3.3  COMMAND  OPERATION  PROCEDURE  (COP) 

The  Conunand  Operation  Procedure  fully  specifies  the  closed-loop  protocols  executed  by  the 
sending  and  receiving  ends  of  the  Transfer  layer  of  the  TC  System.  The  COP,  which  exists 
wholly  within  the  Transfer  layer,  consists  of  a  pair  of  synchronized  procedures  for  each 
Virtual  Channel:  a  Frame  Operation  Procedure  (FOP)  that  executes  within  the  sending 
entity;  and  a  Frame  Acceptance  and  Reporting  Mechanism  (FARM)  that  executes  within  the 
receiving  entity.  The  sending  FOP  transmits  TC  Frames  to  the  receiving  FARM.  The 
FARM  returns  telemetered  Command  Link  Control  Words  (CLCWs)  to  the  FOP  and  thus 
closes  the  loop  by  providing  reports  of  the  status  of  frame  acceptance. 

The  COP  provides  a  basic  Quality  Of  Service  (QOS)  within  the  Transfer  layer  that  is  central 
to  the  operation  of  the  TC  System,  i.e.,  the  delivery  of  data  units  to  the  receiving  end  of  the 
layer  above,  correct  and  without  omission  or  duplication,  and  in  the  same  sequential  order  in 
which  they  were  received  from  the  layer  above  at  the  sending  end. 

Only  one  COP  is  defined  in  this  Recommendation:  COP-1. 

CAUTION 

THE  CONTROLLING  SPECIFICATIONS  FOR  THE  LOGICAL  OPERATIONS 
WHICH  MUST  BE  EXECUTED  TO  PERFORM  THE  COP  ARE  CONTAINED  IN  A 
MORE  DETAILED  CCSDS  RECOMMENDATION  (REFERENCE  [7]).  IN  THE 
EVENT  OF  ANY  CONFLICT  BETWEEN  THE  DESCRIPTIVE  TEXT  CONTAINED 
IN  THIS  RECOMMENDATION  AND  THE  TEXT  OF  REFERENCE  [7],  THE  MORE 
DETAILED  SPECIFICATIONS  CONTAINED  IN  REFERENCE  [7]  SHALL 
PREVAIL. 
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Underlying  the  Transfer  layer  is  the  physical  telecommand  data  channel  which  interconnects 
its  sending  and  receiving  ends.  If  a  perfect  data  channel  existed,  the  QOS  would  be  assured 
since  the  exact  duplicate  of  the  series  of  data  units  which  was  input  to  the  sending  end  would 
appear  at  the  receiving  end.  However,  space  data  channels  are  noisy  and  may  introduce 
errors  or  discontinuities  into  transmitted  data  streams.  The  job  of  the  COP  within  the 
Transfer  layer  is  therefore  to  ensure  the  correctness,  completeness  and  sequentiality  of  the 
delivered  data  units,  in  the  presence  of  such  errors  or  discontinuities  introduced  by  the  layer 
below. 

Correctness  of  the  delivered  data  units  is  guaranteed  (within  known  error  probabilities)  by 
means  of  the  error-protection  encoding  applied  by  the  Channel  Service,  and  by  the  Frame 
Validation  Check  performed  by  the  Transfer  layer.  However,  validation  of  the  completeness, 
sequentiality  and  non-duplication  of  the  delivered  data  units  on  a  particular  Virtual  Channel 
requires  that  a  frame  accounting  (i.e.,  numbering)  scheme  be  implemented  by  the  COP. 

FARM-1  permits  Type- AD  frames  to  be  accepted  only  if  they  are  received  bearing  absolute 
FRAME  SEQUENCE  NUMBERS  which  are  in  the  proper  up-counting  sequential  order; 
upon  detection  of  the  first  frame  sequence  error,  the  FARM  will  reject  all  subsequent  Type- 
AD  frames  on  that  Virtual  Channel  which  do  not  contain  the  expected  FRAME  SEQUENCE 
NUMBER,  and  the  FOP  must  go  back  n  frames  and  resume  sequential  retransmission  by 
repeating  all  unacknowledged  Type- AD  frames. 

Type-BC  frames  are  used  to  send  Control  Commands  to  the  FARM.  Type-BD  frames  are 
processed  by  the  COP  only  to  the  extent  of  causing  the  FARM  to  increment  the  FARM-B 
COUNTER  in  the  CLCW. 
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ANNEX A 

DATA  ROUTING  SERVICE 
ACRONYMS  AND  TERMINOLOGY 


(THIS  ANNEX  IS  PART  OF  THE  RECOMMENDATION) 


Purpose: 

This  Annex  defines  the  key  acronyms  and  terms  which  are  used  throughout  this 
Recommendation  to  describe  activities  within  the  Segmentation  and  Transfer  Layers. 
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ACRONYMS 


A: 

B: 

CCSDS; 

CLCW: 

COP: 

COP-I; 

CTRL: 

FARM: 

FARM-1: 

FOP: 

FOP-1: 

ID: 

MAP: 

MSB: 

N(R): 

N(S): 

QOS: 

RForrf: 

TC: 

TF: 

VC: 

V(R): 


ACCEPTANCE  CHECK  MODE 
BYPASS  MODE 

CONSULTATIVE  COMMITTEE  FOR  SPACE  DATA  SYSTEMS 

COMMAND  LINK  CONTROL  WORD 

COMMAND  OPERATION  PROCEDURE 

COMMAND  OPERATION  PROCEDURE  #1 

CONTROL 

FRAME  ACCEPTANCE  AND  REPORTING  MECHANISM 

FARM  PART  OF  COP-1 

FRAME  OPERATION  PROCEDURE 

FOP  PART  OF  COP-1 

IDENTIFIER 

MULTIPLEXER  ACCESS  POINT 
MOST  SIGNIFICANT  BIT 

THE  OBSERVED  VALUE  OF  V(R)  CONTAINED  IN  ONE  CLCW 

TRANSMITTED  FRAME  SEQUENCE  NUMBER 

QUALITY  OF  SERVICE 

RADIO  FREQUENCY 

TELECOMMAND 

TRANSFER  FRAME 

VIRTUAL  CHANNEL 

RECEIVER_FRAME_SEQUENCE_NUMBER 
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TERMINOLOGY 


CODING  LAYER: 

The  top  layer  of  the  Channel  Service,  specified  in  Reference  [4].  This  is  the  layer 
immediately  below  the  Transfer  layer. 

COMMAND  LINK  CONTROL  WORD  (CLCW): 

The  CLCW  is  the  protocol  data  unit  for  TC  reporting  via  telemetry  from  the  FARM  back  to 
the  FOP.  The  CLCW  resides  wholly  within  the  Transfer  layer,  though  it  does  include  a  few 
parameters  describing  the  readiness  state  of  lower  layers,  which  aid  the  efficient  operation  of 
the  COP.  The  CLCW  does  not  perform  any  reporting  service  for  the  Segmentation  layer. 

COMMAND  OPERATION  PROCEDURE  (COP): 

A  sequence  of  procedural  activities  designed  to  assure  the  reliable,  error-controlled  delivery 
of  a  TC  Transfer  Frame  across  the  Transfer  layer.  The  COP  consists  of  a  Frame  Operation 
Procedure  (FOP)  operating  within  the  sending  end  of  the  layer  and  a  Frame  Acceptance  and 
Reporting  Mechanism  (FARM)  operating  within  the  receiving  end  of  the  layer. 

COP-1  =  Sequential  acceptance  and  retransmission  with  frame  sequence  numbering. 

CONTROL  COMMAND: 

A  special  Type-B  TC  Frame  which  carries  control  instructions  in  its  Data  Field  to  set  up  the 
internal  operating  parameters  of  the  FARM. 

CONTROL  INSTRUCTION: 

Information  that  is  required  to  set  up  a  TC  System  layer  to  support  the  handling  of 
telecommands. 

DATA  START: 

A  signal  from  the  Coding  layer  which  becomes  “true”  to  notify  the  Transfer  layer  that  valid 
decoded  data  octets  are  being  transferred. 

DATA  STOP: 

A  signal  from  the  Coding  layer  corresponding  to  Data  Start  becoming  “false”,  which  notifies 
the  Transfer  layer  that  no  more  valid  data  octets  are  being  transferred  by  the  layer  below. 

FARM-B  COUNTER: 

A  counter,  reported  in  the  CLCW,  which  increments  once  for  every  Type-B  frame  that  is 
accepted  by  the  FARM  on  a  particular  Virtual  Channel. 
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FILL  DATA: 

Extra  trailing  octets  of  meaningless  data  added  by  the  sending  end  Coding  layer  to  complete 
the  last  TC  Codeblock.  Because  information  in  the  TC  Transfer  Frame  is  needed  by  the 
receiving  end  to  determine  how  much  Fill  Data  has  been  added,  Fill  Data  must  be  removed 
by  the  receiving  end  Transfer  layer,  not  by  the  receiving  end  Coding  layer. 

FRAME  ACCEPTANCE  AND  REPORTING  MECHANISM  (FARM): 

The  FARM  is  the  set  of  procedures  executed  by  the  receiving  end  of  the  Transfer  layer  to 
decide  whether  to  accept  a  TC  Transfer  Frame  and  how  to  report  operation  and  status  back  to 
the  FOP  via  Conunand  Link  Control  Words. 

FRAME  OPERATION  PROCEDURE  (FOP): 

The  FOP  is  the  procedure  executed  by  the  sending  end  of  the  Transfer  layer  to  transmit  a  TC 
Transfer  Frame.  The  FOP  conducts  a  transfer  sequence  using  the  communication  services  of 
the  underlying  TC  Channel  Service.  Actions  of  the  FOP  are  dictated  by  the  rules  of  the  COP 
and  the  FARM  status  information  passed  back  to  it  via  the  telemetered  Command  Link 
Control  Word  (CLCW). 

FRAME  SEQUENCE  NUMBER  N(S): 

The  up-counting  absolute  number  that  is  placed  into  each  Type-A  TC  Frame. 

FRAME  VALIDATION  CHECK: 

A  set  of  common  integrity  and  quality  tests  to  which  ALL  TC  Transfer  Frames  are  first 
subjected  when  they  are  processed  by  the  receiving  end  of  the  Transfer  layer. 

LOCKOUT: 

A  condition  whereby  the  FARM  has  detected  a  severe  sequentiality  anomaly  and  rejects  all 
subsequent  Type-A  frames  until  reset  by  a  Type-B  UNLOCK  Control  Command. 

MULTIPLEXER  ACCESS  POINT  (MAP): 

A  MAP  is  a  mechanism  provided  within  the  Segmentation  layer  to  allow  different  user  data 
structures  to  be  multiplexed  together  for  transmission  on  one  Virtual  Channel  provided  by  the 
Transfer  layer.  Multiplexing  allows  user  data  structures  with  different  delivery  priorities  to 
share  the  same  Virtual  Channel  and  thus  provides  flow  control. 

NEXT  EXPECTED  FRAME  SEQUENCE  NUMBER  N(R): 

The  observed  eurrent  value  of  V(R)  that  is  telemetered  from  the  FARM  to  the  FOP  via  each 
CLCW. 
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PACKETIZATION  LAYER: 

The  bottom  layer  of  the  Data  Management  Service,  specified  in  Reference  [3].  This  is  the 
layer  immediately  above  the  Segmentation  layer. 

RECEIVER_FRAME_SEQUENCE_NUMBERV(R): 

The  value  of  the  Frame  Sequence  Number,  N(S),  which  the  FARM  expects  to  see  in  the  next 
Type-A  frame  in  order  to  preserve  up-counting  sequence. 

RETRANSMIT: 

A  flag  indication  from  the  FARM,  contained  in  a  CLCW,  that  at  least  one  Type-A  frame  has 
been  rejected  and  that  retransmission  is  required  from  the  FOP. 

SEGMENTATION  LAYER: 

The  top  layer  of  the  Data  Routing  Service,  which  interfaces  user  data  structures  with  the 
protocols  used  during  transfer  to  the  receiving  spacecraft. 

TELECOMMAND  FRAME  DATA  UNIT  (TC  FRAME  DATA  UNIT) 

The  data  unit  generated  by  the  Segmentation  layer  to  be  placed  in  the  data  field  of  the  TC 
Transfer  Frame  which  will  convey  the  data  to  the  spacecraft.  It  will  consist  of  a  TC  Segment, 
one  or  more  complete  TC  Packets  or  a  single  TC  User  Data  Unit. 

TELECOMMAND  SEGMENT  (TC  SEGMENT): 

The  protocol  data  unit  of  the  TC  Segmentation  layer.  A  TC  Segment  consists  of  a  Segment 
Header  and  Segment  Data  Field. 

TELECOMMAND  TRANSFER  FRAME  (TC  TRANSFER  FRAME  or  TC  FRAME): 

The  protocol  data  unit  of  the  Transfer  layer.  TC  Transfer  Frames  contain  a  Frame  Header,  a 
Frame  Data  Field,  and  an  optional  Frame  Error  Control  Field.  The  Data  Field  carries  either  a 
TC  Frame  Data  Unit  (e.g.,  a  TC  Segment  or  TC  Packet(s))  or  a  Control  Command,  which 
establishes  the  internal  operations  of  the  Transfer  layer. 

TELECOMMAND  USER  DATA  UNIT  (TC  USER  DATA  UNIT): 

A  finite-length  user  data  structure  provided  by  the  layers  above  to  be  carried  from  the  ground 
to  the  spacecraft.  If  the  layer  above  the  Segmentation  layer  is  the  Packetization  layer,  the  TC 
User  Data  Unit  will  be  a  TC  Packet.  If  the  layers  above  the  Segmentation  layer  do  not 
conform  to  the  CCSDS  telecommand  architecture,  the  TC  User  Data  Unit  may  be  any  other 
higher-layer  user  data  structure.  Certain  services  of  the  Segmentation  layer  are  provided  only 
for  TC  Packets. 


CCSDS  202.0-B-2 


Page  A-5 


November  1992 


CCSDS  RECOMMENDATION  FOR  TELECOMMAND:  DATA  ROUTING  SERVICE 


TRANSFER  LAYER: 

The  bottom  layer  of  the  Data  Routing  Service,  which  performs  the  transfer  of  user  data 
structures  to  the  receiving  spacecraft. 

TYPE-A  (ACCEPTANCE  MODE)  FRAMES: 

TC  Transfer  Frames  which  have  a  flag  set  indicating  that  they  are  to  be  tested  against  the 
Frame  Acceptance  Check. 

TYPE-B  (BYPASS  MODE)  FRAMES: 

TC  Transfer  Frames  which  have  a  flag  set  indicating  that  they  are  NOT  to  be  tested  against 
the  Frame  Acceptance  Check,  but  should  be  delivered  as  soon  as  they  pass  the  Frame 
Validation  Check. 

UNLOCK: 

A  Type-B  Control  Command  which  resets  a  FARM  LOCKOUT  condition. 

VIRTUAL  CHANNEL  (VC): 

Virtual  Channels  are  provided  by  the  Transfer  layer,  which  interfaces  with  the  single  physical 
channel  in  the  layers  below  and  presents  the  service  of  apparently  separating  this  single 
channel  into  multiple  “virtual”  paths  to  the  Segmentation  layer. 

A  Virtual  Channel  (VC)  is  simply  a  unique,  multi-bit  ID  code  assigned  to  a  particular 
sequence  of  TC  Transfer  Frames  to  enable  all  the  frames  which  are  members  of  that  sequence 
to  be  identified.  When  different  Virtual  Channel  IDs  are  assigned  to  different  TC  Transfer 
Frame  sequences,  the  sequences  can  be  multiplexed  onto  the  physical  channel  at  the  sending 
end  and  then  sorted  at  the  receiving  end  back  into  their  proper  parent  sequences.  Necessarily, 
when  Virtual  Channels  are  not  used,  the  physical  channel  in  concept  is  the  same  as  one 
Virtual  Channel.  Virtual  Channels  provide  an  alternative  method  for  multiplexing  user  data 
structures  if  the  multiplexing  feature  of  the  Segmentation  layer  is  not  used. 

WAIT: 

An  indication  from  the  FARM,  contained  in  a  CLCW,  that  the  receiving  end  of  the  Transfer 
layer  has  encountered  congestion  in  passing  data  to  the  layer  above  and  cannot  accept  any 
more  Type- A  frames. 
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ANNEX  B 

DATA  ROUTING  SERVICE  SPECIFICATION 


(THIS  ANNEX  IS  PART  OF  THE  RECOMMENDATION) 


Purpose: 

This  Annex  provides  the  detailed  specification  of  the  service  provided  by  the  Segmentation 
and  Transfer  layers. 
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B-1  OVERVIEW  OF  THE  LAYERS  WITHIN  THE  DATA  ROUTING  SERVICE 

The  Data  Routing  Service  is  implemented  using  two  layers  of  protocol:  the  Segmentation 
layer  and  the  Transfer  layer.  The  function  of  the  Segmentation  layer  is  to  prepare  user 
telecommand  messages  for  transmission  to  the  spacecraft,  using  services  of  the  Transfer 
layer,  by  forming  them  into  TC  Frame  Data  Units.  The  function  of  the  Transfer  layer  is  to 
reliably  move  Transfer  Frames  from  the  sending  end  of  the  Telecommand  System  to  the 
receiving  end,  using  the  Channel  Service,  including  retransmission  of  any  frames  which  were 
found  by  the  receiving  end  to  have  been  damaged  or  lost  during  transfer. 

A  diagram  defining  the  principal  elements  within  the  Data  Routing  Service  is  presented  in 
Figure  B-1. 

Higher-layer  TC  User  Data  Units  (e.g.,  TC  Packets)  may  range  in  length  from  very  short 
units  to  very  long  ones.  The  characteristics  of  the  physical  data  channel  which  interconnects 
the  sending  and  receiving  end  of  the  system  are  such  that  the  most  effective  method  of 
transmission  requires  intermediate  length  (up  to  8  k  bit)  data  structures  (see  Reference  [2]). 
Furthermore,  since  this  physical  data  channel  has  a  finite  data-carrying  capacity,  a  method 
must  be  provided  to  prevent  one  user  from  monopolizing  the  channel  to  the  exclusion  of 
others.  The  task  of  the  Data  Routing  Service  is  therefore  to  provide  the  transformation 
between  the  characteristics  of  the  user  layers  of  the  TC  System  and  the  constraints  of  the 
physical  channel,  including  breaking  large  user  messages  into  smaller  eommunications- 
oriented  pieces  or  aggregating  very  small  user  messages  into  larger  pieces  and  multiplexing 
these  pieces  to  provide  responsive  virtual  access  to  the  channel  for  all  users. 

A  “TC  Segment”  is  the  specific  form  of  the  “TC  Frame  Data  Unit”  containing  a  Segment 
Header. 

B-2  TC  SEGMENTATION  LAYER  SERVICE  SPECIFICATION 

The  services  provided  by  the  Telecommand  Segmentation  layer  are  as  follows: 

(1)  The  layer  breaks  long  user  data  structures  from  the  layer  above  (i.e.,  TC  Packets, 
or  other  user  data  structures  which  have  been  generated  by  a  non-standard  higher 
layer)  into  pieces  (“TC  Frame  Data  Units”)  which  will  fit  the  data  field  of  TC 
Transfer  Frames,  and  reassembles  them  after  passage  through  the  Transfer  layer. 

(2)  The  layer  optionally  aggregates  multiple  TC  Packets  into  a  single  TC  Frame  Data 
Unit,  which  fits  into  the  data  field  of  a  TC  Transfer  Frame  and  separates  them 
after  passage  through  the  Transfer  layer. 

(3)  The  layer  provides  a  mechanism  for  multiplexing  different  TC  Frame  Data  Units 
together  onto  a  single  Virtual  Channel,  for  the  purpose  of  flow  control. 

The  Segmentation  serviee  described  in  this  Recommendation  is  designed  to  support  the 
standard  CCSDS  telecommand  Packetization  layer  (Reference  [3]).  It  can  also  provide 
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services  to  other  non-standard  higher-layer  TC  processes  as  long  as  the  interface 
requirements  of  the  Segmentation  layer  are  satisfied. 
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Figure  B-1:  TC  Data  Routing  Service  Elements 
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B-2.1  Segmentation  Layer:  Sending  End  Service  SpeciBcation 

(1)  INPUTS 

From  the  Packetization  layer  or  other  layer  above: 

(a)  Transportable  TC  User  Data  Units  (e.g.,  TC  Packets)  which  are  to  be  routed 
to  the  spacecraft.  The  length  of  the  TC  User  Data  Unit  is  unconstrained; 
however,  if  they  are  TC  Packets,  then  each  will  have  a  maximum  length  of 
65542  octets. 

(b)  Control  instructions  which  are  required  in  order  to  transfer  the  user  data 
structures  to  the  spacecraft.  Those  control  instructions  specifying  delivery 
priority  are  read  and  processed  by  the  Segmentation  layer  and  establish  the 
multiplexing  hierarchy  within  this  layer.  Other  control  instructions  (e.g., 
directives  to  abort  specific  commands)  are  passed  through  to  the  layer 
below. 

NOTE:  The  abstract  content  and  concrete  format  of  the  control  instructions 
are  not  presently  specified  and  remain  an  item  for  potential  future 
extension. 

From  the  receiving  end  of  the  Segmentation  layer: 

None. 

From  the  Transfer  layer  below: 

(c)  Information  describing  the  status  of  transfer  of  TC  Frame  Data  Units 
through  a  given  Virtual  Channel. 

(2)  OUTPUTS 

To  the  Packetization  layer  or  other  layer  above: 

(a)  Information  describing  the  status  of  transfer  of  TC  User  Data  Units. 

To  the  receiving  end  of  the  Segmentation  layer: 

None. 
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To  the  Transfer  layer  below: 

(b)  User  data  structures  which  have  been  formed  into  TC  Frame  Data  Units. 

(c)  Control  instructions,  possibly  passed  through  from  the  layer  above. 

(3)  INTERNAL  FUNCTIONS 

(a)  Assigns  individual  TC  User  Data  Units  to  particular  Multiplexer  Access 
Points  (MAPs)  for  routing  to  the  spacecraft  through  a  Virtual  Channel  (VC) 
provided  by  the  Transfer  layer. 

(b)  Breaks  or  aggregates  the  TC  User  Data  Units  into  pieces  which  are 
compatible  with  insertion  into  the  data  field  of  the  TC  Frame  Data  Unit. 

(c)  Optionally  labels  each  piece  with  sequence  control  and  MAP  identification 
information  to  create  a  TC  Segment.  The  TC  Segment  or  the  piece  from  (b), 
if  the  Segment  Header  is  not  used,  becomes  the  TC  Frame  Data  Unit. 

(d)  Multiplexes  TC  Frame  Data  Units  from  different  MAPs  together  onto  one 
Virtual  Channel  for  flow  control  purposes. 

(e)  Monitors  the  process  of  transferring  TC  Frame  Data  Units  through  Virtual 
Channels  by  the  layers  below,  and  maintains  cognizance  of  the  status  and 
availability  of  particular  Virtual  Channels. 

B-2.2  Segmentation  Layer:  Receiving  End  Service  Specification 
(1)  INPUTS 

From  the  Packetization  layer  or  other  layer  above: 

(a)  Information  concerning  the  ability  of  the  higher  layer  to  accept  more  data. 

From  the  sending  end  of  the  Segmentation  layer: 

None. 

From  the  Transfer  layer  below: 

(b)  TC  Frame  Data  Units  in  sequence  and  complete,  without  omission  or 
duplication  (if  sent  as  Type- A  Frames). 
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(2)  OUTPUTS 

To  the  Packetization  layer  or  other  layer  above: 

(a)  Reconstructed  User  Data  Units. 

To  the  sending  end  of  the  Segmentation  layer: 

None. 

To  the  Transfer  layer  below: 

(b)  Information  concerning  the  ability  of  the  Segmentation  layer  to  accept  more 
data. 

(3)  INTERNAL  FUNCTIONS 

(a)  Receives  TC  Frame  Data  Units  from  the  Transfer  layer,  delivered  on 
individual  Virtual  Channels. 

(b)  Sorts  TC  Frame  Data  Units  associated  with  individual  VCs  according  to 
their  MAP  identifier  and  reassembles  the  Segments  associated  with  a 
particular  MAP  to  reconstruct  the  TC  User  Data  Unit. 

(c)  Determines  when  all  TC  Segments  associated  with  a  particular  TC  User 
Data  Unit  have  been  received  correctly. 

(d)  Extracts  the  TC  Packets. 

(e)  Passes  the  reconstructed  TC  User  Data  Units  to  the  Packetization  layer  or 
other  higher  layer. 


B-3  TC  TRANSFER  LAYER  SERVICE  SPECIFICATION 

The  service  provided  by  the  TC  Transfer  Frame  layer  is  to  encapsulate  Data  Units  within  a 
suitable  data  structure,  the  TC  Transfer  Frame,  for  transmission  through  the  physical  channel 
which  interconnects  the  sending  and  receiving  ends  of  the  TC  System,  and  to  reliably  convey 
them  without  detected  error  from  the  sending  to  the  receiving  ends  of  the  layer. 

Efficient  telecommand  operation  can  usually  be  achieved  when  the  Channel  Service 
(Reference  [2])  rejects  less  than  1  frame  per  10^  frames  transmitted.  To  achieve  the 
performance  required  for  a  particular  mission,  an  acceptable  combination  of  Channel  Service 
parameters  (e.g.,  codeblock  decoding  method,  number  of  contiguous  TC  Codeblocks,  error 
characteristics  of  the  physical  layer)  must  be  selected.  Information  on  the  frame  rejection 
performance  is  given  in  Reference  [2]. 
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Project  operations  are  compromised  by  undetected  frame  errors.  The  selected  Channel 
Service  parameters  not  only  control  the  frame  rejection  rate  but  also  dictate  the  inherent 
undetected  frame  error  rate.  If  the  undetected  frame  error  rate  provided  by  the  Channel 
Service  is  inadequate  for  a  project’s  needs,  the  Cyclic  Redundancy  Check  described  in  sec 
4.2. 1.3  should  be  applied  to  the  transfer  frame  to  bring  this  error  rate  into  conformance. 
Information  on  undetected  frame  error  performance  is  given  in  Reference  [2]. 

B-3.1  Transfer  Layer:  Sending  End  Service  Specification 

(1)  INPUTS 

From  the  Segmentation  layer  above: 

(a)  TC  Frame  Data  Units. 

(b)  Control  instructions,  Management  Directives  and  Data  Transfer  Requests 
for  the  FOP.  (See  Reference  [7]  for  details.) 

From  the  receiving  end  of  the  Transfer  layer: 

(c)  Information  concerning  the  status  of  receipt  of  individual  TC  Frames, 
formatted  into  a  Command  Link  Control  Word  (CLCW)  and  extracted  from 
the  Telemetry  Transfer  Frame  (Reference  [5])  or  the  Virtual  Channel  Data 
Unit  (Reference  [8]). 

From  the  Coding  layer  below: 

(d)  Status  of  the  physical  channel. 

(2)  OUTPUTS 

To  the  Segmentation  layer  above: 

(a)  Status  of  the  data  routing  process,  including  the  progress  of  delivering 
individual  TC  Frame  Data  Units  and  the  availability  of  Virtual  Channels. 

To  the  receiving  end  of  the  Transfer  layer: 

(b)  “Control  Command”  TC  Transfer  Frames,  which  instruct  the  receiving  end 
how  to  accept  and  report  the  received  frames. 

To  the  Coding  layer  below: 

(c)  Buffers  of  TC  data  bits  containing  protocol  data  units  from  the  TC  Transfer 
layer  (i.e.,  one  or  more  TC  Transfer  Frames). 
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(d)  Control  instructions  defining  the  operational  procedures  to  be  used  to 
transmit  the  buffer  of  bits  to  the  spacecraft. 

(3)  INTERNAL  FUNCTIONS 

(a)  Encapsulates  TC  Frame  Data  Units  into  TC  Transfer  Frames. 

(b)  Translates  control  instructions  received  from  layers  above  into  the 
appropriate  set  of  operational  procedures  to  be  used  to  transfer  the  TC 
Transfer  Frames  to  the  spacecraft,  including  selection  of  the  correct  mode 
(Acceptance  Test  or  Bypass)  of  the  Command  Operation  Procedure  (COP). 

(c)  Creates  Control  Command  TC  Transfer  Frames  for  transmission  to  the 
receiving  end  of  the  layer  in  order  to  control  the  Frame  Acceptance  and 
Reporting  Mechanism  (FARM). 

(d)  Supervises  the  transfer  of  TC  Transfer  Frames  to  the  receiving  end  by 
executing  a  Frame  Operation  Procedure  (FOP)  in  aceordance  with  the 
selected  mode  of  the  COP. 

(e)  Retransmits  TC  Frames  as  required  to  rectify  channel-induced  errors. 

(f)  Responds  to  control  instructions  from  layers  above  to  abort  command 
transmission  by  issuing  the  appropriate  set  of  control  instructions  to  the 
layer  below. 

B-3.2  Transfer  Layer;  Receiving  End  Service  Specification 
(1)  INPUTS 

From  the  Segmentation  layer  above: 

(a)  Information  defining  the  ability  of  the  Segmentation  layer  to  accept  more 
data  (optional). 

From  the  sending  end  of  the  Transfer  layer: 

(b)  Control  Command  TC  Transfer  Frames  which  contain  instructions  defining 
how  the  data-carrying  TC  Transfer  Frames  are  to  be  processed. 

From  the  Coding  layer  below: 

(c)  “Clean”  octets  of  decoded  TC  data.  (Note:  only  correct  data,  which  have 
passed  the  decoder  quality  check,  will  normally  be  reeeived.) 
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(d)  “Data  Start”  signal  (indication  of  the  start  of  the  first  valid  octet  of  TC  data). 

(e)  “Data  Stop”  signal  (indication  of  the  last  valid  octet  of  TC  data).  (Note: 
trailing  octets  of  Fill  Data  could  be  present  just  before  the  Data  Stop  signal 
is  received.) 

(f)  Control  information  describing  the  status  of  the  physical  channel  (e.g.,  rf 
and  bit  synchronization). 

(2)  OUTPUTS 

To  the  Segmentation  layer  above: 

(a)  TC  Frame  Data  Units  which  have  been  extracted  from  TC  Transfer  Frames 
that  passed  the  validation  and,  optionally,  the  acceptance  tests. 

To  the  sending  end  of  the  Transfer  layer: 

(b)  CLCWs  which  will  be  utilized  by  the  FOP  to  control  the  transmission  of 
additional  TC  Transfer  Frames,  or  the  retransmission  of  previously  sent 
frames,  in  accordance  with  the  rules  of  the  COP. 

To  the  Coding  layer  below: 

None. 

(3)  INTERNAL  FUNCTIONS 

(a)  Responds  to  Control  Command  TC  Transfer  Frames  received  from  the 
sending  end  of  the  layer. 

(b)  Performs  the  Frame  Validation  Check  Procedure  for  all  TC  Transfer  Frames 
and  the  frame  acceptance  checks  of  the  Frame  Acceptance  and  Reporting 
Mechanism  for  Type-A  Frames. 

(c)  Creates  reports  (CLCWs)  to  the  sending  end  describing  the  status  of  TC 
Transfer  Frame  acceptance. 

(d)  Processes  TC  Transfer  Frames  which  have  been  retransmitted  as  required  to 
rectify  channel-induced  errors. 

(e)  Extracts  TC  Frame  Data  Units. 

(f)  Passes  the  extracted  TC  Frame  Data  Units  to  the  Segmentation  layer. 
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(g)  Responds  to  control  instructions  from  layers  below  to  abort  command 
transmission  by  ceasing  the  processing  of  the  current  TC  Transfer  Frame, 
and  awaiting  new  control  instructions. 
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